Gold Medal Software 1

home *** CD-ROM | disk | FTP | other *** search

/ Gold Medal Software 1 / Gold Medal Software Volume 1 (Gold Medal) (1994).iso / drivers / load221.arj / LOAD.DOC < prev next >

Wrap

Text File | 1993-11-06 | 32KB | 629 lines

╒════════════════════════════════════════════╕ │ LOAD & UnLOAD │ │ Revision 2.21.0 │ │ │ │ Copyright (C) 1991-1993 FM de Monasterio │ │ Licensed Material. All rights reserved │ ╘════════════════════════════════════════════╛ CONTENTS: 1. SUMMARY 2. REGISTRATION 3. GENERAL INFORMATION 4. PROGRAM INFORMATION 5. PROGRAM USAGE 6. LOADING IN UPPER MEMORY 7. BASIC TECHNICAL INFORMATION 8. OPERATION REQUIREMENTS & CONFLICTS 9. COPYRIGHT & LICENSE INFORMATION 1. SUMMARY LOAD permits the loading of a device driver directly from the DOS-command line without having to edit the CONFIG.SYS file and rebooting the system. For character (but not block) device drivers, LOAD provides the option of installing the device drivers in the upper memory area, i.e., below 1,024 KB, the upper 086 memory limit of DOS, and above 640 KB, the IBM hardware barrier, known as UMA, to preserve conventional memory (except for a 1-KB resident gateway). UMA loading requires an XMS manager 2+ and DOS 3+. A device driver LOADed directly from the DOS command line can be unlinked from the driver chain and removed from memory with the associated utility UnLOAD, or by selecting switch U of LOAD to release the allocated memory. Hence, LOAD/UnLOAD allow for treating device drivers simply as a resident programs that can be installed and uninstalled on the fly. See LOAD.NEW for a description of what is new with the current version. 2. REGISTRATION This software is user-supported; the present release, although lacking the options marked by asterisks, is a fully usable program. You may test this release for (in)compatibilities with your system, but after the testing is completed you are requested to order a registered copy of the full release of the software from the address at the end of this documentation. If you would rather use this unregistered copy, consider making a donation to the Children's Hospital of Washington DC, for indigent children in need of medical care. Every year in the USA, infant mortality claims the lives of tens of thousands of children before their first year of life, and most of them come from families below poverty level... Please send to the same address a check payable to the "PATIENT CARE FUND, CHILDREN'S HOSPITAL" on the obverse, and marked "For Deposit Only" on the reverse. Donations will be sent to Children's Hospital. Please identify the program for which you are making the donation. ------------------------------------------------------------------- LOAD.REG contains a form needed to register or upgrade the Software ------------------------------------------------------------------- See the final part of this documentation for information on the Licensing, Distribution, and Limited Warranty of this software. 3. GENERAL INFORMATION The computer operating system communicates with the outside world through peripheral devices. Device drivers are programs that provide an interface between DOS and a physical, i.e., disk hardware, or virtual device, i.e., RAM disk software. DOS distinguishes two main types of installable device drivers: BLOCK (or disk-type) and CHARACTER (or nondisk-type) devices. A block device driver must be able to support one or more 'logical' (viz., physical or virtual) disks, and thus be able to transfer data in groups of characters. Whereas character device drivers typically transfer data one character at a time, the primary feature of this class of driver is that the peripheral device is not a 'logical' disk, as character devices can also support group-mode data transference. Typical examples of such types are 2 programs provided with MS-DOS: ANSI.SYS is a character device driver for the replacement of the standard 'console' (keyboard and video display) driver that DOS loads when it is first started; RAMDRIVE.SYS is a block device driver to create a RAM-disk in memory. Since their introduction in MS-DOS version 2, installable device drivers are usually installed, i.e., loaded, during the DOS initialization after after the computer boots up. The file CONFIG.SYS specifies the names of these devices with the 'DEVICE=' or 'DEVICEHIGH=' command. In addition, DOS provides no means of removing an installed driver. (Once a driver is loaded, the system needs to be rebooted with a different CONFIG.SYS file to remove such a driver. LOAD/UnLOAD allow dealing with device drivers as if they were terminate- and-stay resident programs which can be loaded at any time from the DOS- prompt command line and can be removed, also from the DOS prompt, at any time. 4. PROGRAM DESCRIPTION For character (but not block) device drivers, LOAD provides the option of installing such device drivers in upper conventional memory, i.e. between 640 KB, the so-called 'hardware DOS barrier,' and 1024 KB, the 1-MB upper limit of DOS-addressable memory. This range is known as the upper memory area (UMA), and its allocatable blocks are known as UMBs. Loading into a UMB preserves the amount of conventional memory used by DOS, except for a small memory wedge described below. To be able to unload the driver, LOAD also installs a small memory wedge in conventional memory, which is used both as a memory marker and a data storage buffer, of about 1 KB. This wedge is referred to as the 'device driver gateway' throughout this documentation. LOAD has a number of 'sanity-checks' and error-trapping routines to allow a more or less graceful exit when a driver crashes, but in some cases you may need to reboot the system. Read the error messages listed in the file LOAD.MSG to get an idea of the checks performed by LOAD. LOADING DRIVERS Drivers distributed with DOS as well as many other commercial drivers can be LOADed successfully. Due to the complexity of the operations, however, you will have to find by trial and error which installable device drivers can be LOADed in your system from the DOS command line. Erratic behavior has been detected in (some) block device drivers if they are loaded in the upper memory area via switch /H of LOAD (see below). To avoid this problem, only character device drivers can currently be loaded via LOAD in the upper memory. This safety limitation will be bypassed by block device drivers masquerading as character device drivers, such as CD ROM drivers. (CD-ROM manufacturers supply a device driver that makes them look like character driver, and require a resident program such as MSCDEX [Microsoft CD Extensions] to make the CD-ROM look like a DOS disk.) UNLOADING LOADED DRIVERS Drivers installed from the DOS command line, either in the lower or upper conventional memory, can be uninstalled with UnLOAD (or with LOAD /U). If more than one driver has been LOADed, the reverse order of loading should be used for their UnLOADing; to do otherwise may produce conflicts in the operation of DOS or at least of some drivers. When uninstalling a driver, UnLOAD restores the contents of the interrupt table maintained by the BIOS to those copied prior to the installation of the device driver. It then releases all (lower) memory allocated between the resident driver (or, for a UMA-loaded driver, the driver gateway) and UnLOAD; and then it releases the resident driver itself. This means that resident programs installed in lower conventional memory after the driver (or its gateway) will be uninstalled as well, since their resident memory blocks will be deallocated. Also notice that expanded or extended memory allocated by such residents is not released and does not become available to the EMS or XMS pool. In contrast, resident programs installed in the upper conventional memory after the device driver was loaded will *not* be released but will remain orphaned in the UMA since any interrupt service they may have been hooked to is now disconnected from them. UnLOAD does not release the UMBs where such programs reside, since given the vagaries of UMB allocation strategy it would be too costly (in terms of size of the resident memory wedge) to determine which UMB residents were installed before and after the driver. UNDOCUMENTED DOS SERVICES LOAD uses a few undocumented services which are supported in version 2.00 through 6.00 of MS-DOS and other MS-compatible versions. The careful use use of undocumented functions is not a negative feature of LOAD. In fact, many undocumented services are crucially necessary in a sizable number of commercial programs, including MS-DOS itself. The manner in which undocumented DOS data are obtained by LOAD depends on the version of DOS in use and the support it provides; whenever possible, LOAD performs 'sanity-checks' and provides error-trapping procedures when using undocumented DOS features. For instance, the so-called DOS List of Lists is obtained through a memory search in some buggy versions of DOS 4 but via an undocumented DOS service in other versions (except when such a a service is found to be not supported, in which case the [slower] search method is used). REQUIREMENTS LOAD/UnLOAD require MS-DOS or PC-DOS version 2 to 6 or a fully compatible operating system; they are incompatible with DR-DOS and OS/2-DOS. For UMA loading/unloading, LOAD/UnLOAD require the presence of an extended memory manager (XMM) supporting version 2.0 of the extended memory specification (XMS). Such XMM must be already loaded and capable of supporting XMS UMB functions. XMMs require DOS version 3 or later. CPU VERSIONS The program is written in assembly language; each version consists of four processor-type releases (086, 268, 386 and 486) in which the code has been optimized for the CPU types of the 80x86 processor family. This is needed since the x86 processors differ markedly in instruction execution time and the incorporation of a memory cache in some CPU types affects such time by influencing the speed of instruction fetching and of memory access. A 486 release should be used with a 586 CPU (Pentium) to minimize degradation of performance vis-á-vis code alignment. In addition to standard (086) assembly language instructions, the 286, 386 and 486 releases of the program also use 286-, 386- or 486-specific opcode instructions in "real" mode (which is the native mode for 086 processors). The type and degree of code optimization vary with the CPU type, and yield relatively small differences in the resident size, which is less than 1000 bytes. SAFETY MEASURES Each time it is executed, the program verifies its code integrity through a number of cyclic redundancy checks (CRCs). Program execution is aborted if any check were to fail as such a failure indicates code corruption and the program should not be used for your own protection. The executable program is distributed as a fully encrypted and compressed EXE-type file in order to reduce disk storage and the possibility of code tampering. The file size expands on execution by a factor of 2 or less. NOTE -------------------------------------------------------------------- Because both encryption and compression change the code sequences to different values, it cannot be excluded that these processess might, by chance, yield an encrypted data sequence which triggers a warning from antiviral utilities that merely check disk-stored files against a list of code 'signatures' or instructions. Though all distribution diskettes are scanned with one such utility to avoid the possibility of spurious warnings, the changing nature of these 'signature' lists makes this exclusion difficult. If using these utilities, check the registered distribution diskette before installing the programs in your hard disk, and please contact the vendor (see below) if a spurious warning were triggered. -------------------------------------------------------------------- 5. USAGE In these descriptions, {} enclose context variables, e.g., the number {n}, while <> enclose alphanumeric characters or keys, e.g., the letter <n>. Program usage is very simple: LOAD [/H[n]] {DriverFile} and UNLOAD {Gateway} or LOAD /U {Gateway} in which {DriverFile} is the complete drive\path\file specification of the driver file to be installed, whereas {Gateway} is the name of the resident device gateway, name which is always provided to the user by LOAD when the driver is loaded. The resident gateway name can also be determined at any time with a memory map utility (such as MAPMEM.COM of TurboPower Software). The name consists of 8 characters; for a block device, this string has the format 'DRIVE_d:' (in which 'd' is the letter designator of the block device drive), whereas for a character device, this string is the actual device name in which all blank padding spaces (if any) have been changed to the underline character (ASCII code 95). For example, the driver ANSI.SYS (which has the reserved name 'CON ') yields the gateway name 'CON_____' upon installation. SWITCHES The switches are not case sensitive. They must be preceded by a slash [/] and they must precede the specification of the driver file to be loaded or the driver gateway to be annulled: -------------------------------------------------------------------------- Switches marked with asterisks are available only in the registered copy -------------------------------------------------------------------------- * SWITCH H[n] Instructs LOAD to install the (character) driver in upper memory between 640 KB and 1024 KB, i.e. below the 1 MB boundary of conventional RAM but above the 640-KB hardware barrier. The switch requires that an extended memory manager (XMM) supporting the services of the XMS 2.00 or later be installed, and that a free upper memory block (UMB) of the size required by the driver be available. (See below 'Loading in Upper Memory'). A lower high-memory limit for the UMB can optionally be specified by {n} (a hexadecimal number between A000 [640 KB] and FFFF [1024 KB]) so as to avoid specific areas of memory having a slow access time; notice that if {n} contains less than 4 hexadecimal digits or an invalid digit (neither 0-9 nor A-F) the default minimum limit of n=A000 is used. Note ------------------------------------------------------------------- The address and size of available UMBs can be obtained via MEM.EXE, when DOS controls UMB allocation, or via the memory manager itself, when this allocation is controlled by 386-specific memory managers. In either case, such data can also be obtained with UMAX.EXE, a UMB mapping utility that is distributed by the author. If memory access time is a critical element in the selection of the UMBs, a detailed timing access map is provided by TIMEM.EXE, a utility which is also distributed by the author. ------------------------------------------------------------------- The size required by the driver is the length of code to remain resident in memory after an initialization check in conventional memory. Because of such check, any driver installation banner will be displayed twice if switch H were specified. UMA-loading creates a small memory resident in lower conventional memory of about 1 KB. The resident contains a gateway to the actual driver, and driver and UMB data needed for unloading. Block device drivers cannot be installed in upper memory with the current version of LOAD. Example: LOAD /HCC00 ANSI.SYS This requests that the driver ANSI.SYS, located in the default drive and directory (no drive or path specified), be loaded in upper memory higher than or at the (hexadecimal) address limit CC00h. Default: Invalid /Hn = /HA000. * SWITCH U Uninstalls a previously loaded device driver, which is identified by the associated {Gateway} resident name that must be given after this switch. The same operation is provided by UnLOAD, and the following descriptions apply to both LOAD /U and UnLOAD. The nullification procedure unlinks the driver from the DOS driver chain and, for a block device, the corresponding drive from a DOS drive table. Before attempting to release the memory being used by the device driver, UnLOAD changes both the name and attribute of the device to those of the NUL device, the input/output bit bucket for DOS, as a protection in case the unlinking of the driver (or the release of its memory) were to fail. Since the true NUL device is always the last device in the driver chain, any other NUL device is ignored. In addition, the gateway of an annulled device is renamed 'unLOADed' to facilitate its detection in memory maps. UnLOADing a device driver also uninstalls memory-resident utilities that may have been installed after the driver was LOADed, and the contents of a table of interrupt addresses maintained by the BIOS at absolute memory segment 0 are changed to those values present immediately before loading the driver. These effects are the same as those produced by TSR-removal utilities. When the same resident name is present in lower conventional memory more than once, i.e. when the same driver has been LOADed more than once, the first occurrence of the name is used and its associated driver annulled. DOS ERRORLEVELS Upon completion, the program passes an errorlevel value which can be used to check (via ERRORLEVEL commands in a batch file) the outcome of program execution. The following errorlevels may be passed: Value Nature of Error ----- ------------------------------------ 255 32-bit CRC failed 255 CPU does not support code 224 DOS does not support fxn 21/52h 192 DOS does not support fxn 21/32h 160 Failed to found NUL driver 128 Invalid DOS version 112 Critical error 96 Removal error 80 XMS error or XMM missing 64 All drives assigned (maximum) 32 All drives assigned (inc no.) 16 Driver initialization error 8 0-unit on block device driver 4 0-byte driver break length 2 Overlay driver load failed 1 Driver name not given 0 Successful execution 6. LOADING IN UPPER MEMORY This section describes in more detail aspects of the installation of the driver in the upper memory region. The allocation of UMA blocks (UMBs) is arbitrated by an XMS manager (XMM) version 2.0 or higher; the XMM must be installed prior to the UMB-loading of the resident. Allocation also requires the remapping of UMA addresses by a UMB provider, when such a task is not implemented by the XMM itself. The XMM HIMEM.SYS and the UMB-provider EMM386.EXE are distributed with MS DOS 5+. The allocation of UMBs is controlled by DOS when these 2 drivers are installed, and the command <dos=umb> is added to the CONFIG.SYS file. With DR-DOS 6+, UMB remapping and XMS support are provided by EMM386.SYS. Other 386-specific memory managers, of course, also provide UMB remapping and XMS support. All XMMs require MS-DOS version 3 or later. Switch Hn, in which A000 ≤ {n} ≤ FFFF (hexadecimal), allows the selection of a minimum upper-memory limit for the UMB to avoid UMA regions having a very slow access time (or to preserve regions with a fast access time for other utilities that require faster times, such as a disk cache or screen accelerator), or to avoid fragmentation of the UMA when UMB allocation is not controlled by MS-DOS 5+, but by the XMM itself. The fragmentation may occur when the XMM allocates blocks on a first-fit basis, i.e., the first available UMB having the lowest UMA address is allocated, irrespective of whether or not a (smaller) block matching the requested size is available at a higher UMA address. Unless the size of the available UMBs increases with increasing memory address, first-fit allocation of a small UMB leads to the breaking of large UMA blocks into smaller ones, thus hampering the UMB installation of larger residents. If MS-DOS 5+ controls UMB allocation, the program enforces the allocation of the resident block on a best-fit basis when {n} is not specified, that is, all available blocks are searched (by DOS), and the one matching most closely the size requested is allocated. When DOS controls UMB allocation and {n} is specified, UMBs are allocated on a first-fit basis. While this may contribute to UMA fragmentation, it allows for the checking of a minimum memory limit in those cases in which the selection or avoidance of a specific UMA region is more important. 7. TECHNICAL INFORMATION INTERRUPTS Whenever certain conditions occur, either within a program or the system, it becomes necessary for the processor to interrupt its current operation and execute one of a group of special routines. The action that triggers the execution of such a routine is referred to as an interrupt; there are internal interrupts, in response to a state of the CPU or an instruction, and external interrupts, caused by signals sent to the CPU from elsewhere in the system. When loading a driver, LOAD intercepts the following interrupts to verify the status of the loading process: INT 00h - Divide Exception INT 08h - Hardware System Timer INT 24h - DOS Critical Error INT 2Fh - XMS Interface INT 67h - EMS Interface Because of undocumented behaviors of some device drivers (e.g., Microsoft RAMDRIVE.SYS), this interception is done in a less traditional, but fully transparent manner to the loaded drivers, especially with the application program interface for XMS (INT 2Fh). LOAD releases these interrupts once the driver is successfully loaded. A brief description of the interrupts is given below: Interrupt 00h is triggered by conditions causing a divide overflow, as in the case of a zero divisor, or a dividend too large for the divisor. LOAD monitors this interrupt, assuming that its occurrence indicates a loading incompatibility (at least for debugged drivers). Interrupt 08h is triggered 18.2 times per second by channel 0 of the 8253 /8254 timer chip, and is used by the system time-of-day count. LOAD uses this interrupt to provide a time-out safety exit in case the driver hangs during loading. Interrupt 24h is triggered by a critical error during read and write file or device operations. LOAD monitors this interrupt to determine if driver path specification provided by the user is a correct one. Interrupt 2Fh is used to provide a motley of services for MS-DOS, WINDOWS and third-party applications, including the address of the XMM interface. LOAD monitors this interrupt to determine if the driver allocates any XMS blocks during initialization. Interrupt 67h provides the EMS interface. LOAD monitors this interrupt to determine if the driver allocates any EMS blocks during initialization. 8. OPERATION REQUIREMENTS AND CONFLICTS LOADed/UnLOADed require MS-DOS or IBM PC-DOS version 2-6, and other fully compatible operating systems; LOAD/UnLOAD are not compatible with any DOS version of OS/2 (compatibility box) or with DR-DOS. LOADING LIMITATIONS Some device drivers cannot be loaded from the DOS command line with LOAD. In some cases, this is because the driver needs to be installed within 64 KB from the BIOS data area (e.g., some drivers that increase the keyboard buffer); in other cases, this is because the driver is in conflict with a previously loaded resident; and in some other cases, this is because of a conflict between the behavior the driver and that expected by LOAD. Most cases involve block device drivers. UNLOADING LIMITATIONS During the initialization of a driver being installed, LOAD checks if the device driver requests expanded (EMS 3.0+) or extended memory (XMS 2.0+); the latter includes the allocation of extended memory blocks (EMB), upper memory blocks (UMB), and the High Memory Area (HMA). UnLOAD attempts the release of allocated EMS or XMS memory, or both. Neither LOAD nor UnLOAD can determine whether the driver has released allocated EMS or XMS memory prior to the unloading; were the release to occur, the system might crash if the same EMS or XMS handle was assigned to a different process *after* its release by the driver. EMS- or XMS-based devices having resizable capabilities, such as some RAM disks, create the distinct possibility of the above problem when resizing involves first deallocation and then reallocation of memory that yields a 'handle' value different to the original one. 9. COPYRIGHT & LICENSE INFORMATION This documentation, programs, and other files distributed in this software package (the "Software") are the copyrighted property of FM de Monasterio (the "Author"), who provides the Software and licenses its use. All rights are reserved. The Software is not sold. A license fee is required to use this Software. This license does not transfer to you either the ownership of or the title to the Software, which remain the property of the Author. A form required to license the Software is provided in the enclosed file LOAD.REG. SINGLE USER LICENSE. Grants you use of this Software in a single computer at a time; the Software may be transferred to another computer, as long as it is used only in 1 computer at any time; under the license, the Software may NOT be installed on a network server. SITE/15-PCs LICENSE. Grants you use of this Software in a sigle site or a set of sites, as long as the Software is not used in more than 15 machines at a time, and that such machines are located exclusively within the site. Licenses for more machines are available at discounted prices. SOFTWARE BUNDLING LICENSE. Please write to the Author. REFUNDS POLICY. If a problem notified within ninety (90) days of shipping of the registered copy cannot be solved, the registration fee (but not the shipping costs) will be refunded upon receiving a written request with the original diskette(s) enclosed. UPGRADE POLICY. Program upgrades are limited to licensed users. Upgrades within the same major version (e.g. release 4.00 through 4.99) are free of charge when a self-addressed, stamped, 5.25" diskette mailer with a 360-KB diskette is included with the request. Other upgrades are charged half the (single-user/site) registration fee. See the enclosed file LOAD.UPG. U.S. GOVERNMENT INFORMATION The Software is Commercial Computer Software under the Federal Acquisition Regulations of the U.S. government and the Agency Supplements to them. The Software is provided to the Federal Government and its agencies only under the Restricted Rights Provisions of the above noted regulations applicable to commercial software developed at private expense, and not in the public domain. The use, duplication, or disclosure of the Software by the Federal Government or its agencies is subject to the restrictions set forth in the subdivision (c.1.ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 (October 1988) and FAR 52.227-19 (June 1987). DISTRIBUTION You may distribute the Software, but you are specifically prohibited from: - Charging fees or asking donations in exchange of or payment for copies of this Software. - Distributing this Software with commercial products without the written, express permission in advance from the author. - Distributing this Software via a for-profit organization or group, either alone or with other software. - Changing any of the contents of this Software including the copyright notice and license information. You may not disassemble or otherwise reverse engineer the Software. Other uses of the Software are prohibited without a written authorization signed by the Author. Latest program releases may be found at the Information Exchange BBS (703) 836-0748, as a compressed archive file. WARRANTY DISCLAIMER FOR UNREGISTERED COPIES The information contained in the documentation for the Software is subject to change without notice. The Author cannot and does not warrant that any functions contained in the Software will meet your requirements, or that its operations will be error free. The entire risk as to the Software performance or quality, or both, is solely with the user and not the Author. You assume responsibility for the selection of the Software to achieve your intended results and for the installation, use, and results obtained from the Software. The Author makes no warranty, either implied or expressed, including with- out limitation any warranty with respect to this Software documented here, its quality, performance, or fitness for a particular purpose. In no event shall the Author be liable to you for damages, whether direct or indirect, incidental, special, or consequential arising out the use of or any defect in the Software, even if the Author has been advised of the possibility of such damages, or for any claim by any other party. All other warranties of any kind, either express or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose, are expressly excluded. By using the Software, you acknowledge (1) to have read and understood all parts of this document and (2) to have agreed with and accepted all of its terms and provisions without any reservation. For information on the terms of the Limited Warranty for licensed Software copies or any other information on this program, please write to: FM de Monasterio P.O. Box 219 Cabin John, MD 20818-0219 USA ┌─────────────────────────────────────────────────────────────┐ │ Trademarked names are the property of the respective owners │ └─────────────────────────────────────────────────────────────┘ [End]